Make the getMessage function for the javascript example more robust.

[qdirks]

The old getMessage function had a bug where if you made multiple unawaited calls to the function, it wouldn't behave correctly because previous reads had not yet completed, and all you were doing was reading 4 bytes at a time from the input into the header buffer. It also had a bug of not reading the correct amount of data, because the buffer given to the read function was not exactly sized for the expected message size, so it was possible that the amount of data that you got back was larger than the size that the header indicated if the extension had sent more than one message.

The new getMessage function solves both of those issues. The first issue is solved by using a promise and a while loop to trap the execution of extra calls at the top of the function while there is already a read in progress. Each call to getMessage is let through the trap one at a time as a read completes. If there are no pending reads, then a call to getMessage does not get trapped at the top of the function, because the read promise will be null, and so the loop will be skipped. The other issue is solved by using buffers which are appropriately sized according to the header information. I think this is also more succinct, since the old readFullAsync ultimately ended up doing that anyway at the end by passing the data array to the Uint8Array constructor. If you just create it from the header information and pass it directly to the read function, you can avoid dispatching to another function, and it prevents a bug.

Description

Make the getMessage function better for the javascript example.

Motivation

The change will prevent the bugs I described, which makes it easier to develop a native messaging extension for the next person, I hope.

Additional details

https://nodejs.org/api/fs.html#filehandlereadbuffer-options

Related issues and pull requests

[github-actions]

Preview URLs

• /en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

(comment last updated: 2025-05-30 04:10:38)

[Josh-Cena]

Please make sure your code follows our style guide. In particular:

1. Do not use underscore-prefixed variables, and use camelCase.
2. Names like rs_rp and rp don't mean anything to me. Use full words that make sense.
3. There's no bug about "unawaited calls", because all calls are awaited in our example (we show you how getMessage should be used). If your calls to getMessage are different then that's really a bug in your code. You seem to be implementing a lock with your _rp but again the variables are poorly named and I can't read the code. I wouldn't recommend implementing a lock yourself though; it's too much mechanism for a trivial demo.

I understand the part about the size mismatch though. I don't know why the original version is using a loop instead of preallocating the whole thing.

[qdirks]

@Josh-Cena Thank you for your feedback. I made some changes to it which I hope you'll accept. Totally understand if you don't want to put this on MDN, though. Let me know if you would accept it if the variables were named differently or something like that. Thanks.

[Josh-Cena]

Thanks, this looks much better now. I made some tiny updates to your code, mainly wrapping it with try...finally to make sure the lock gets released in all cases. This looks good to me stylistically, but I'm unaware whether it's fully correct and whether the looping read in the original code is intended, so I'll defer to the WebExt team to review it.

Addressed

[qdirks]

@Josh-Cena Good idea on the try/finally

[qdirks]

One more tiny change, which is just to close the file handle from within the finally block as well.

[qdirks]

Oops, I need the loop to be able to get the entire message. But we can do better than the original code by keeping track of the offset into the message buffer where new data needs to be inserted, and by not reading more than the length indicated by the header by passing that offset to the read method along with the message buffer. I think... I think this is ready now. I'll grant you, the code became longer than I had hoped, but I think this finally solves all of the issues I had.

2 notes which you may want to add about the example:

• This code won't work on windows, because it accesses a file path ('/dev/stdin') which does not exist on windows.
• The maximum string size in NodeJS is somewhere around 500 megabytes, at least on my machine. I wasn't able to create strings larger than that. You might want to know that if you're trying to TextDecoder.decode the message into a string, and then JSON.parse it, since everything the extension sends to your native app is JSON.

I may eventually try to re-write this to work on both Linux and Windows using all of the knowledge I gained here, unless somebody beats me to it.